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The traditional split-up into a low level language and a high level language in the design 
of computer algebra systems may become obsolete with the advent of more versatile 
computer languages. We describe GiNaC, a special-purpose system that deliberately 
denies the need for such a distinction. It is entirely written in C++ and the user can 
interact with it directly in that language. It was designed to provide efficient handling 
of multivariate polynomials, algebras and special functions that are needed for loop 
calculations in theoretical quantum field theory. It also bears some potential to become 
a more general purpose symbolic package. 



1. Introduction 

HistoricaUy, in the design and implementation of symbolic computation engines, the 
focus has always been rather on algebraic capabilities than on language design. The need 
for efficient computation in all fields of science has led to the development of powerful 
algorithms. Thus, the border line between inexact numerical and exact analytical compu- 
tation has moved, such that more computation may be done exactly before resorting to 
numerical methods. This development has had great influence on the working practice in 
such fields as engineering (e.g. robotics), computer science (e.g. networks), physics (e.g. 
high energy physics) and even mathematics (from group theory to automatic theorem 
proving in geometry). 

This border line between analytical and numerical methods, however, has quite often 
remained a painful obstacle in the successful application of computer algebra systems 
(CASs). Usually, some results are obtained with the help of a CAS and later these results 
are integrated into some other program. This is not only restricted to numerical results, 
where one frequently translates the output of some CAS to C or even FORTRAN. It is 
questionable whether the distinction between one language for writing down symbolical 
algebra and one for obtaining numerical results and maybe a third one for integrating 
everything in a graphical user interface has any reason other than historical ones. In our 



experience it frequently leads to confusions; the xloops project (Briichcr et ai, 1998) 
has somewhat suffered from this. 



The chapter "A Critique of the Mathematical Abilities of CA Systems" in (Wester 
1999| ) has a section called "Mathematics versus Computer Science" where some misbe 



haviours of common CASs are shown. There, the first test tries to find out if a global 
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variable is accessed in some local context, in particular within sums, products, limits 
and integrals. Of the seven systems tested, only Derive passed the test. Even explicitly 
declaring a variable to be local does not always spare the programmer surprises: MapleV 
Releases 3 to 5 for instance do not honor local variables if they are created by concate- 
nating strings using the operator dot ( . ) , a feature people often feel tempted to use for 
elegant subscripting. So created variables may be used as lvalues in assigning a local 
variable within a procedure but the result is a modified global variable.^ Such violations 
of scope have repeatedly led to subtle bugs within xloops. They are notoriously difficult 
to disentangle since they go undetected until some other part of the program breaks. 

The general picture is that most currently used CASs are linguistically rather impover- 
ished and put up high obstacles to the design of combined symbolical/numerical/graphical 
programs. An incomplete look into the toolchest of a C++ developer throws some light 
on the features that any professional programmer will miss from common CA systems: 



structured data types like structs and classes instead of unnamed lists of lists, 
the object oriented (00) programming paradigm in general, 

templates, which allow for generic (i.e. type-independent) programming even in a 
strongly typed language, 

the Standard Template Library (STL), which provides convenient classes for many 
kinds of containers with asymptotically ideal access methods and to a large degree 
container- independent algorithms (sort, etc) to be instantiated by the programmer, 
modularization facilities like namespaces, 

powerful development tools like editors (e.g. with automatic indentation and syntax 
highlighting), debuggers, visualization tools, documentation generators, etc., 
flexible error handling with exceptions, 

last, but not least: an established standard ( |IS0/IEC 14882-1998(E)|) which guards 
the programmer from arbitrary changes made by the manufacturer which break 
existing code. 



Solutions for those problems so far are restricted to allowing calls to CAS functionality 
from other languages and the already mentioned code generators. At most, bridges are 
built to cross the gap, no unification of the two worlds is achieved. 



1.1. The goal 



Loop calculations in quantum field theory (QFT) are one example for such a combined 
symbolical and numerical effort. The n-fold nested integrals arising there are solved with 
specialized methods that demand efficient handling of order 10^-10^ symbolic terms. At 
the one-loop level, Feynman graphs can be expressed completely analytically and so in 
the early 90's our group started to build up the program package xloops based on Maple. 
The continuation of xloops with Maple up to the two-loop level turned out to be very 
difficult to accomplish. There were numerous technical issues of coding such as the ones 
outlined above as well as a nasty restriction built into MapleV of no more than 2^^ terms 
in sums. 

An analysis of xloops showed, however, that only a small part of the capabilities of 



t We have been told that Maple6 still suffers from this problem. 
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Maple is actually needed: composition of expressions consisting of symbols and elemen- 
tary functions, replacement of symbols by expressions, non-commuting objects, arbitrar- 
ily sized integers and rationals and arbitrary precision floats, collecting expressions in 
equal terms, power series expansion, simplification of rational expressions and solutions 
of symbolic linear equation systems. 

It is possible to express all this directly in C++ if one introduces some special classes of 
symbols, sums, products, etc. More generally, one wishes to freely pass general expressions 
to functions and back. Here is an example of how some of these things arc actually 
expressed in C++ using the GiNaC0 framework: 

1 #include <ginac/ginac .h> 

2 using namespace GiNaC; 

3 

4 ex HermitePoly (const symbol & x, int n) 

= { 

6 const ex HGen = exp(-pow(x,2) ) ; 

7 // uses the identity H_n(x) == (-l)~n exp(x~2) (d/dx)~n exp(-x~2) 

8 return normal (pow (- 1 ,n) * HGen.diff(x, n) / HGen); 

« } 

10 

11 int main(int argc, char **argv) 

12 { 



13 int degree = atoi (argv [1] ) ; 

14 numeric value = numeric (argv [2] ) ; 

15 symbol z("z") ; 

16 ex H = HermitePoly(z, degree) ; 

17 cout « "H_" « degree « " (z) == " 

18 « H « endl; 

19 cout « "H_" « degree « "(" « value « ") == 

20 « H. subs(z==value) « endl; 

21 return 0; 



22 } 

When this program is compiled and called with 11 and 0.8 as command line arguments 
it will readily print out the 11th Hermite polynomial together with that polynomial 
evaluated numerically at z — 0.8: 

1 H_ll(z) == -665280*z+2217600*z-3-1774080*z-5+506880*z-7-56320*z-9+2048*z-ll 

2 H_ll(0.8) == 120773.8855954841959 

Alternatively, it may also be called with an exact rational second argument 4/5: 

1 H_ll(z) == -665280*z+2217600*z~3-1774080*z-5+506880*z~7-56320*z-9+2048*z-ll 

2 H_ll(4/5) == 5897162382592/48828125 

It calls the subroutine HermitePoly with the symbolic variable z and the desired order as 
arguments. There, the Hermite polynomial is computed in a straightforward way using 
a Rodrigues representation. The normal () call therein cancels the generators HGen in 
numerator and denominator. Note that the operators * and / have been overloaded 
to allow expressive construction of composite expressions and that both object-style 
method invocations ( obj . f ( arg) ) as well as function-style calls (f ( obj, arg) ) are possible. 
Technically, the whole GiNaC library is hidden in a namespace that needs to be imported 



t GiNaC is a recursive acronym for GiNaC is Not a CAS. 
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(for instance with the using directive in hne 2) in order to aUow easy integration with 
other packages without potential name clashes. This is just a crude example that invites 
for obvious refinement like parameter checking or rearranging the polynomial in order to 
make it less sensitive to numerical rounding errors. 

Since pattern matching is something that doesn't blend very naturally into the con- 
text of a declarative language like C++ , GiNaC takes care to use term rewriting systems 
which bring expressions into equivalent canonical forms as far as feasible in an economic 
way. In addition, specialized transformations may be invoked by the user, for instance 
an . expand ( ) method for fully expanding polynomial s or a . normal ( ) m ethod for poly- 
nomial GCD cancellation. As for instance in Form ( Vermaseren, 1991 ) the user alone 
is responsible for deciding the order of steps to take in some application, there are only 
very few rules built into GiNaC. The only kind of pattern matching we want to allow 
is an atomic one, where inside an expression a symbol (or a list of symbols) is replaced 
by other expressions in this fashion: (5*a) .subs(a==b) 5*b. We believe that such 
a conservative restriction should be acceptable to programmers of large systems since 
the potential ambiguities introduced by pattern matching and overlapping rules can be 
rather subtle. 



2. The implementation 

The implementation of GiNaC follows an 00 philosophy: all algebraic classes that 
may be manipulated by the system are derived from an abstract base class called basic^. 
Some of the classes are atomic (symbols, numbers. . . ), others are container classes (sums, 
products. . . ). Since at run-time container classes must be flexible enough to store different 
objects whose size must, however, be defined already at compile-time, we define the class 
of all expressions, simply called ex. It is a wrapper class that stands outside the class 
hierarchy and it contains mainly a pointer to some object of the class hierarchy. The 
container classes thus may be restricted to hold objects of the wrapper class ex (figure |l]). 
Because of this "handle" character, objects of class ex are also the ones the user creates 
most of the time. Most operators have been overloaded to work within this class and they 
are the most common arguments to the functions in GiNaC. Two obvious drawbacks of 
this flexibility are the lack of type-safety at compile-time and possible performance losses 
by additional function calls in method invocations. To some extent, this can be remedied 
by carefully overloading specialized functions and operators. On the other hand, the 
interplay between ex and basic (and all classes derived from it) enables us to implement 
an efficient memory management using reference counting and copy-on- write semantics: 
multiply occurring expressions (or subexpressions within an expression tree) are shared 
in memory and copied only when they need to be modified in one part of the program. 
This happens in a completely transparent way for the user. In order to create one's own 
classes managed this way it suffices to derive them from class basic. 

Table |l| gives an overview of what classes are currently provided by GiNaC. We are 
now going to describe some of them. 



t Strictly speaking, GiNaC docs not have any abstract base classes in the C++ sense, since there are 
defaults for all methods. We therefore define an abstract base class to be one which does not make sense 
to instantiate. 
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2.1. Numbers 



Arbitrarily sized integers, rationals and arbitrary precision floating point numbers are 
all stored in the class numeric. This is an interface that encapsulates the foundation class 
cl_N of Bruno Haible's C++ library CLN (Haible, 2000) in a completely transparent way. 

The choice fell to CLN because it provides fast and asymptotically ideal algorithms 
for all basic operations (Karatsuba and Schonhage-Strassen multiplication) and a very 
flexible way of dealing with rationals and complex numbers. Also, it does not put any 
burden of memory management on us since all objects are reference-counted — ^just like 
GiNaC's — so there are no interferences with garbage collection. Its polymorphic types 
are perfectly suited for implementing a CAS, and indeed were written with this intention 
in mind. For instance, it honors the injection of the naturals into the rationals and of the 
complex numbers into the reals: Rationals are instantanously and efficiently normalized 
to coprime integer numerator and denominator and converted to integers if the result- 
ing denominator is unity and complex numbers are instantanously converted to reals 
if the imaginary part vanishes. Non-exact numbers, i.e. floats and complex floats are 
constructed with any user-defined accuracy. 

GiNaC provides functions and operators defined on class numeric to the user so the 
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class 


description 


examples 


symbol 


algebraic symbols 


X 


numeric 


polymorphic CLN numbers 


42, |i, 0.12345678 


constant 


symbols with associated numeric 


TT 


add 


sums of expressions 


a - 26 -1- 3 


mul 


products of expressions 


2a'^{x+y+z)/b 


power 


exponentials 


x^, a(''+=), V2 


pseries 


truncated power series 


X- \x^ +0{x^) 


function 


symbolic functions 


sui{2x) 


1st 


list of expressions 


[i, 2y, 3 ^- 


relational 


relation between two expressions 


x==y 


matrix 


matrices (and vectors) of expressions 


1 X 
^ -X 1 ' 


ncmul 


container for non-commutative objects 


7071 


color, coloridx 


SU{3) Lie algebra element, -index 


'^a, ^abi fabc 


lortensor, lorentzidx 


Lorentz tensor, -index 





Table 1. List of the most important classes from figure [l| and their purpose. 



wrapper class ex may be circumvented. This provides both some level of type-safety as 
well as a considerable speedup. 

2.2. Symbols and Constants 

Symbols are represented by objects of class symbol. Thus, construction of symbols is 
done by statements like symbol x,y;. In a compiled language like C++ the name of a 
variable is of course unavailable to the running program. For printing purposes therefore 
a constructor from a string is provided, i.e. symbol x("x") ,y("y") ; . This is reminiscent 
of Common Lisp's ( Steele, 1990D concept of print name. The responsibility for not mixing 



up names (as in symbol x("y") ,y("x") ;) is entirely laid on the user. The string is not 
at all used for identification of objects. If omitted, the system will still deal out a unique 
string. 

Unlike in other symbolic system evaluators, expressions may not be assigned to sym- 
bols. This is a restriction we had to introduce for the sake of consistency in the non- 
symbolic language C++. It is, however, possible to substitute a symbol within an expres- 
sion with some other expression by calling the . subsO method. 

Objects of class constant behave much like symbols except that they must return some 
specific number (if possible to arbitrary accuracy) when the method .evalf () is called. 
There are several predefined constants like tt etc. which have an associated function for 
numerical evaluation to arbitrary accuracy. Another possibility is an associated fixed 
precision numeric. Thus, physical constants are easily constructed by the user, as in this 
fragment: 

1 constant qeC'qe" , numeric (1 . 60219e-19) ) ; // elementary charge 

2 cout « qe « endl; // prints 'qe' 

3 cout « evalf (qe) « endl; //prints ' 1 . 60219E-19 ' 

2.3. Polynomial arithmetic: the classes add, mul and power 



The main object of interest being efficient multivariate polynomials and rational func- 
tions, GiNaC allows the creation of such objects using the overloaded operators +, -, * 
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Figure 2. Internal representation of the multivariate rational function 
2d3(4a + 5&-3)/e. 



and / and the overloaded function pow(6,e) for exponentiation of expressions b and ej^ 
When such an object is created, the built-in term rewriting rules of the classes add and 
mul are automatically invoked to bring it into a canonical form. Subsequent comparison 
of such objects is then easy and further supported by hash values. Due to the similarity 
in the rewriting rules for sums and products the actual implementation is mostly hidden 
in class expairseq, from which add and mul are derived. The internal representation 
is an unexpanded distributive one. For performance reasons numerical coefficients in 
front of monomials in sums and numerical exponents in products are treated separately 
(as shown in figure |2|). The term rewriting rules for class power are restricted to those 
simplifications that can be done efficiently. 

GiNaC provides the usual set of operations on multivariate polynomials: determination 
of degree and coefficients, expansion of products over sums, collection of coefficients of 
like powers, conversion of rational expressions to a normal form (where numerator and 
denominator are relatively prime polynomials), decomposition of polynomials into unit 
part, content, and primitive part, and polynomial GCD and LCM computation. For the 
latter, GiNaC implements the heuristic polynomial GCD algorithm described in (Liao et 
ai, 1995), augmented by additional heuristics such as cancelling trivial common factors 
(e.g. a;"), eliminating variables that occur only in one polynomial, and special handling 
of partially factored polynomials. If the heuristic algorithm fails, GiNaC falls back to 
the subresultant PRS algorithm ( Geddes et ai, 1992| ). This approach has so far proved 
successful for the application in xloops. 



2.4. Power series: the class pseries 



Expressions may be differentiated with respect to any symbol and also expanded as 
Taylor series or Laurent series. There is no distinction between those two. Series are in- 
ternally stored in a truncated power series representation, optionally containing an order 

t It is also possible to overload operator " for exponentiation in C++, but this would lead to trouble 
since it always has lower precedence than *. 
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term, in a special class pseries. This class implements efficient addition, multiplication, 
and powering (including inversion) of series and can convert the internal representation 
to an ordinary GiNaC expression (polynomial) as well. 

A program fragment where the mass increase from special relativity 7 = (1— (f)^)~^^^ 
is first Taylor expanded and then inverted and expanded again illuminates the behaviour 
and syntax of class pseries to some extent: 

1 symbol v("v") , c("c") ; 

2 ex gamma = l/sqrt(l - pow(v/c,2)); 

3 ex gamma_nr = gamma. series (v==0, 6); 

4 cout « pow(gamma_iir,-2) « endl; 

5 cout « pow(gaimiia_nr,-2) .series(v==0, 6) « endl; 

Raising the series 7 nr to the power —2 in line 4 just returns (l + ^d )^ + |(f )''+C(i^^)) ^• 
Only calling the series method again in line 5 makes the output simplify to 1 — v^/c^ + 

2.5. Functions 

C++ functions arc not suited for symbolic expressions as arguments. This is so because 
if the evaluation engine is unable to evaluate the argument one wishes to return the func- 
tion itself which would lead to an infinite recursion. If x is an indeterminate, then sin(x) 
is supposed to return sin(x). In order to achivc this behaviour the class function is 
introduced. Each object of this class represents a single function (sin, cos. . . ) and meth- 
ods for evaluation, differentiation and so on may be attached to it. The C++ preprocessor 
is then used to define wrapper functions that return the corresponding objects of class 
function. This allows us to write functions down in C++ fashion and obtain the be- 
haviour one knows from usual CASs: 

1 symbol x("x"), yC'y"); 

2 ex Do = Pi*(x+y/2) ; 

3 cout « "sin(" « Do « ") 

4 ex Re = Do . subs (y==i) ; 

5 cout « "sin(" « Re « ") 

6 ex Mi = Re.subs(x==il) ; 

7 cout « "sin(" « Mi « ") 

8 ex Fa = Mi.evalfO; 

9 cout « "sin(" « Fa « ") 

The above fragment prints: 

1 sin(Pi*(x+l/2*y)) -> sin(Pi* (x+l/2*y) ) 

2 sin(Pi*(l/2+x)) -> sin(Pi* (1/2+x) ) 

3 sin(23/2*Pi) -> -1 

4 sin(36. 128315516282622243) -> -1.0 

A great many functions arc already predefined in GiNaC, some of them, however, not yet 
with the full functionality. For instance, polygamma functions may not yet be evaluated 
numerically. 



-> " « sin (Do) « endl; 

-> " « sin (Re) « endl; 

-> " « sin(Mi) « endl; 

-> " « sin (Fa) « endl; 
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3. Benchmarks 



Naturally, we want to know how GiNaC performs in comparison with other systems. 
Therefore we subject it and some other symbolic manipulators to several stress tests on 
different hardware architectures. All tests concentrate on non-C++ arithmetics (arbitrary 
precision instead of hardware-near int, double) and symbolic expressions. GiNaC is 
superior when it comes to algorithms which largely rely on machine-near data types. 
The first two tests were inspired by typical operation patterns in elementary particle 
physics where many different symbols and deeply nested functions need to be handled. 
They are designed to detect flaws in the memory management and the implementation of 
algorithms for manipulation of large container classes (products, sums. . . ). This is done 
by having a close look at the asymptotic runtime behaviour. 

The first test (figure ||, left) consists of three steps: 

1 let e be the expanded sum of n symbols {uq, . . . a„_i} squared: e <— (X]"=o^ '^*)^ 

2 in e substitute oq < 'I2i=2 

3 expand e again, it collapses to ai^. 

The third step is the computationally expensive one. The system has to match terms 
in a sum of w 2n^ elements and eliminate all but one. The timings are taken on an 
AlphaServer 8400 with CPUs of type EV5 running at 300MHz under Digital Unix 4. 
This architecture was chosen specifically in order to give MapleV a chance, which has 
an internal limitation of 2^^ — 1 terms in a sum on any other architecture^. This turns 
out to limit the test to n < 182. This also forced us to resort to a rather old version of 
MuPAD because no newer one is available for the Alpha platform. The tests were run 
until we got bored (which we defined to be 400 seconds). Further continuation also would 
have required more memory since some systems (particularly MuPAD) were allocating 
extraordinary amounts of RAM. The slopes of the curves are interesting: Those systems 
that base their memory management on reference counts exhibit the quadratic scaling 
one would expect from the nature of the test while systems with a garbage collector 
(Maple and Reducs) start off faster and saturate earlier. 

Next, we do a mixed test which besides handling of symbols also involves handling of 
large rational numbers and evaluation of functions at certain points (figure ||, right). We 
calculate the expansion of the Gamma function around the pole at a; = 0. The result up 
to order is: 



It is not completely clear what other systems are doing internally but GiNaC 's imple- 
mentation is simple and lacks any optimization. It falls back to evaluation of Polygamma 
functions ipni^) which in turn requires the evaluation of Riemann's Zeta function if their 
argument is even and, hence, to Bernoulli numbers. We show two curves for Mathemat- 
ica, since this system decides to return the result in the form of unevaluated Polygamma 
functions ipn{^)- If one insists on a result comparable with the other systems one is 
forced to introduce calls to FunctionExpand[] , which slows the system down more than 
an order of magnitude (upper curve). Without FunctionExpand [] its performance is 

t We do not have access to any newer version than Maple VR5. We were informed that the new release 
Maple6 does not suffer from the 2^^ — 1 limitation any longer. 
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Figure 3. Runtimes for a substitute-expand consistency test (left) and for series 
expansion of r(x)\x=o (right). The tests are described in the text. The left graph was 
produced on an AlphaServer 8400, the right one on an Intel P-III. 



only slightly worse than GiNaC's but with a funny excursion at high orders for which 
we do not have an explanation. It should, however, be mentioned that for Mathematica 
that ugly result in terms of 7/'„(l) can under certain circumstances be acceptable since it 
may be handled further without resorting to C- functions. This becomes apparent when 
one tries to evaluate the coefficients in the resulting series numerically. Maple's internal 
limitation results in the breakdown at order n = 35 in this test. 



Next, we apply GiNaC to a number of tests invented by R. Lewis and M. Wester ( Lewi; 



et at, 1999). Strictly speaking, these tests are very much geared towards the particular 
capabilities of the system Fermat. This explains the abundance of benchmarks on Smith 
and Hermite normal forms of matrices with numerical entries. Nevertheless, we tried 
to subject GiNaC to these tests where applicable. [] The benchmarks were rerun on the 
same machine for those systems available to us and the rules of the game were slightly 
simplified: each system was given the chance to run as long as it needed but it was 
not allowed to allocate more than physical memory available. The tests involving finite 
fields and the ones involving Smith and Hermite forms were skipped, since they are not 
applicable to GiNaC. Tests D and E were slightly rearranged in order to give a meaningful 
and comparable result: Maple and MuFAD were forced to cancel common factors in 
the result (using normal), something Pari-GP does automatically. The results shown in 
table I are encouraging but show room for optimization. They also demonstrate some 
improvement of the other systems (notably Singular) over the original test performed 



■t A fair number of these tests even found their way into the suite of GiNaC's regression tests. 



GiNaC 11 







GiNaC 


MapleV 


MuFAD 


Pari-GP 


Singular 


Benchmark 


0.7 


R5 


1.4.1 


2.0.19/3 


1-3-7 


A 


divide factorials ^/'ff.fi'^.Vr' 1 ^-^^^ 

(900+1)! U=l 


n 90 
u. zu 


D.DD 


1. io 


U.O t 


1 Q n 


D 




0.019 


0.08 


0.10 


0.041 


0.54 


c 


gcd(big integers) 


0.25 


10.2 


3.01 


1.65 


0.11 


D 


X — \^ n - - , 

El=ii?'*V(?/ + |5-i|tr 


0.78 


0.13 


1.21 


0.20 


NAt 


E 


U.DO 


U.Uo 


O QQ 
Z.OO 


nil 
U.ii 


1\T A t 


F 


gcd(2-var polys) 


0.08 


0.08 


0.21 


0.057 


0.13 


G 


gcd(3-var polys) 


z.OU 




QUI 

o.oi 


on c; 

yy.o 


U.oo 


H 


det(rank 80 Hilbert) 


10.0 


33.5 


42.5 


3.97 


CR 


I 


invert rank 40 Hilbert 


3.38 


6.41 


12.0 


0.62 


CR 


J 


check rank 40 Hilbert 


1.61 


2.28 


2.95 


0.22 


UN 


K 


invert rank 70 Hilbert 


22.1 


92.0 


74.0 


5.90 


CR 


L 


check rank 70 Hilbert 


9.19 


21.6 


14.2 


1.57 


UN 


Ml 


rank 26 symbolic sparse, det 


0.36 


0.40 


0.75 


0.016 


0.003 


M2 


rank 101 symbolic sparse, det 


1903.3 


GU 


CR 


CR 


251.2 


N 


eval poly at rational functions 


CR 


GU 


CR 


CR 


NA 


Oi 


three rank 15 dets (average) 


43.2 


GU 


CR 


CR 


CR 


O2 


two GCDs 


CR 


UN 


UN 


UN 


UN 


P 


det(rank 101 numeric) 


1.10 


12.6 


44.3 


0.09 


0.85 


P' 


det(less sparse rank 101) 


6.07 


13.3 


46.2 


0.38 


1.25 


Q 


charpoly(P) 


103.9 


1429.7 


741.7 


0.15 


4.4 


Q' 


charpoly(P') 


212.8 


1497.3 


243.1 


CR 


5.0 



Table 2. Runtimes in seconds for the tests proposed by Lewis and Wester (only as far 
as applicable to GiNaC) on an Intel P-III 450MHz, 384MB RAM running under Linux. 
Abbreviations used: GU (gave up), CR (crashed, out of memory), NA (not available), 
UN (unable, a prerequisite test failed). 



by Lewis and Wester. The reader interested in a detailed description of the tests may 



consult (Lewis et al, 199!;) 



4. Conclusions and further work 

Although the GiNaC framework was built specifically to become a symbolic engine for 
complex computations in quantum field theory it is our hope that it turns out to be useful 
for other applications, too. It provides only modest algebraic knowledge; instead it aims 
at being a fast and reliable foundation for combined symbolical/numerical/graphical 
projects in C++ . It may be downloaded and distributed under the terms of the GNU 



general public license from tittp : // www . ginac . de/ . A tutorial introduction and complete 



cross references of the source code can also be found there. 

Because the cycle edit-compile-execute common for all compiled languages may be 
rather tedious during development, care has been taken in the design of GiNaC to permit 
an interactive frontend to the library. Currently, there are two such interfaces. The first 
is the tiny GiNaC interactive shell ginsh for quickly manipulating some expressions. It 
does not provide any programming constructs, only back-reference to the last printed 
expressions. The second is an interface to the Cint C++ interpreter used extensively at 
CERN in the object-oriented data analysis framework ROOT ( Brun et a/., 199^ ). 



t We were informed that benchmarks D and E can indeed be performed with Singular — it is just 
not obvious what the right syntax is. 
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Though at this stage GiNaC is aheady fuUy functional for the apphcations it was orig- 
inally built for, numerous extensions are imaginable. The web page gives some hints in 
this direction and further suggestions are more than welcome, as are third-party contri- 
butions. 
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